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ABSTRACT 
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abstract  machine  running  on  a  VAX  station 
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2.1.  GENERAL  OVERVIEW  OF  SEROUS  ON  THE  PERQ 

SERCUS  is  a  research  implementation  of  a  multi-level  secure  workstation  running  a  classified 
document  handling  system.  The  overall  security  requirement  of  SERCUS  is  that  classified 
information  cannot  be  discovered  by  a  user  with  insufficient  clearance,  eg  a  secret  document 
cannot  be  read  by  a  user  only  cleared  to  restricted 

SERCUS  is  essentially  an  electronic  registry  system  controlling  the  creation  of,  and  access  to 
classified  documents  and  mail  messages.  Users  are  assigned  clearances  which  limit  their 
ability  to  view  and  modify  information  in  the  system.  All  users  have  a  personal  cupboard  where 
they  may  store  obiects  such  as  the  documents  they  are  drafting.  Whilst  in  the  cupboard  these 
objects  may  be  referred  to  by  an  unclassified  name.  A  unclassified  list  is  maintained  of  all  the 
finished  classified  documents  in  the  system,  and  this  is  called  the  Classified  Document  Registry 
(CDR)  Users  n  ay  view  the  CDR  and  ask  to  read  any  of  the  documents  it  holds.  An  additional 
requirement  of  documents  is  that  their  classification  may  be  altered  However  to  ensure  that  the 
new  classification  is  appropriate,  this  requires  the  agreement  of  the  security  officer  in  addition  to 
the  ordinary  user 

SERCUS  also  maintains  a  journal  for  each  document  in  which  interesting  events  that  have 
occurred  in  it’s  life  are  recorded  For  example  which  users  have  accessed  it's  contents,  and  those 
who  have  agreed  to  a  re-classificat.on  of  the  document  Additionally  a  journal  is  maintained  for 
each  user  registered  on  the  system  in  which  security  relevant  actions  are  recorded  such  as  when 
the  user  logs  on  to  and  off  SERCUS,  documents  they  were  prevented  from  seeing  because  their 
clearance  was  insufficient  and  any  users  to  which  the>  have  sent  mail  messages  The  users 
journal  aims  to  make  users  accountable  for  their  actions 

When  a  user  logs  on  to  SERCUS  they  are  presented  with  a  display  consisting  of  a  number  of  non 
overlapping  windows  All  the  window  software  is  completely  trustworthy  le  a  Trusted  path  (A 
trusted  path  is  a  -alidated  link  between  the  human  user  and  a  system's  trusted  software  which 
mutually  authenticates  both  parties )  The  trusted  path  may  be  used  to  invoke  untrusted  software 
such  as  a  commercial  word  processing  package  While  untrusted  software  is  active  in  a  window, 
the  classification  of  tne  information  is  displayed  prominently  SERCUS  monitors  the  movement 
of  information  between  windows  and  uses  a  high  water  mark  mechanism  to  correctly  maintain 
the  classification  levels 

For  more  information  about  the  SERCUS  Secure  Registry  see  RSRE  report, '  An  Example  Secure 
System  Specified  Using  the  Tenry-Wiseman  Approach  ",  Harrold  (1) 

2.2  THE  TEN15  IMPLEMENTATION  OF  SERCUS 

The  present  implementation  **' c  .RCUS  in  TenI5  is  a  demonstrable  subset  of  the  above  The 
Ten  15  SERCUS  incorporates  users,  classifications  and  clearances,  journals  and  documents 
Documents  can  be  created,  opened  and  read,  and  document  and  user  journals  can  be  reviewed  In 
addition,  the  classification  of  a  document  can  found,  as  can  the  clearance  of  a  user  The  system 
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X.  .INTRODUCTION 


This  report  describes  the  implementation  of  a  subset  of  the  SERCUS  demonstration  in  the  abstract 
algebraically  defined,  strongly  typed  language  Tenl5.  Tenl5  contains  constructs  that  implement 
all  of  the  features  of  a  modem  high  level  programming  language,  as  well  as  facilities  for 
manipulating  system  level  aspects  of  a  computer  such  as  filestore. 

A  general  overview  of  SERCUS  as  implemented  on  the  Perq  is  provided,  along  with  a  summary  of 
the  Tenl5  implementation  of  SERCUS  using  the  Tenl5  Cross  Compilation  System  The  use  of  the 
Cross  Compilation  System  is  then  described,  along  with  an  overview  of  the  Tenl5  notation. 

The  report  then  descnbes  in  detail  the  implementation  of  the  individual  modules  making  up  the 
Ten  15  SERCUS  demonstration.  These  include  the  classifications,  context,  journalling,  login 
and  related  procedures,  and  the  registry  modules.  Each  section  describes  the  modes  and  operators 
defined  m  the  module  SercusModesandOps  for  use  in  the  module,  followed  by  descnptions  of  the 
procedures  contained  in  the  module.  The  exception/failure  strategy  employed  in  the  Ten!5 
SERCUS  is  also  descnbed. 

The  convention  used  throughout  the  report  is  thatTenlS  operators  are  bolded  in  the  text,  as  are  the 
names  of  the  modules  used  in  the  SERCUS  demonstration 


can  also  tell  the  user  whether  they  are  on  the  trusted  path,  and  move  users  on  and  off  the  trusted 
path  as  desired  It  should  be  noted  that  the  trusted  path  and  invocation  of  untrusted  software  is  at 
present  only  a  simulation 

The  Tenl5  demonstration,  unlike  the  Perq  version,  has  only  one  window  at  present  It  also  lacks 
High  Water  Marks,  thus  the  creation  of  documents  does  not  perform  high  water  mark  related 
checks  before  a  document  is  created.  Cupboards  and  mail  between  users  has  not  yet  been 
incorporated  either,  and  nor  has  the  regrading  of  documents. 
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3,  .THE  CRQSJSXOMFILAHQN.SYSTEM 


The  subset  of  the  SERCUS  demonstration  descnbed  in  this  report  is  implemented  using  the  Ten  15 
Cross  Compilation  System  on  the  Perq  and  the  VAX  machines  The  VAX  has  only  one  dictionary 
so  there  are  no  separate  users  and  only  one  process  running.  As  yet  there  is  no  Ten  15  notation 
compiler  on  the  VAX,  thus  the  cross  compilation  system  is  vital  in  the  establishment  and 
development  of  software  on  the  VAX  while  completion  of  the  editor  and  notation  compiler  are 
awaited 

This  document  assumes  the  reader  has  a  reasonable  working  knowledge  of  the  FLEX  system 

3.1.  COMPILING  AND  TYPE  CHECKING  A  MODULE 

VAX  modules  for  use  in  the  demonstration  are  written  in  Tenl5  notation  contained  in  edfiles, 
and  compiled  on  the  Perq  Edfiles  and  compiled  modules,  etc,  appear  on  the  Perq  in  the  form  of 
cartouches  (boxes).  An  edfile  c  ntaining  notation  is  first  compiled  by  applying  the  procedure 
make^tenl5  This  procedure  does  the  syntax  checking  of  the  Tenl5  notation  le  it  checks  such 
things  as  declarations  and  scoping,  and  produces  intermediate  Tenfifteen  code  If  a  syntax  error 
is  found,  then  makc_tcnl5  calls  up  the  Perq  editor  which  will  indicate  the  nature  and  position  of 
the  error(s)  When  the  notation  has  been  successfully  checked  syntactically  ie  the  editor  does  not 
get  called,  or  only  gives  warnings  drawing  the  users  attention  to  possible  oversights  in  the 
notation  eg  an  object  which  is  declared  and  not  used  (possible  error  in  the  scope  of  the  object),  then 
the  procedure  vax  is  applied 

The  vax  procedure  does  the  type  checking  and  generates  the  VAX  code  The  type  checking  detects 
illegal  mode  coercion  attempts,  displaying  the  offending  modes  as  cartouches  These  can  be 
duplicated  and  examined  using  the  Show  Tcnl5  Mode  option  on  the  Ctrl  1  menu  (SMITE  Team 
systems  only)  If  the  type  checking  is  unsuccessful,  the  vax  procedure  calls  the  Perq  editor  in  the 
same  way 

The  error  messages  produced  by  both  the  make_tenl5  procedure  and  the  vax  procedure  are  very 
basic  and  not  always  very  helpful  This  is  largely  due  to  the  fact  that  we  are  using  the  first 
embryonic  version  of  the  cross  compilation  system,  and  the  clanty  of  the  error  messages  is  likely 
to  improve  as  the  system  is  further  developed1  The  make_tenl5  and  vax  procedures  are  applied  to 
an  editable  file  (edfile)  as  follows 

ledfilelmakeJenlS1  vax! 

N  B  I  represents  procedure  application  on  the  Perq 

once  the  notation  has  been  successfully  compiled  and  translated,  it  can  either  be  amended  into  ar 
existing  module  or  made  into  a  new  one  as  follows 


1  A  useful  tnck  that  can  be  used  to  check  types  is  to  define  what  you  think  the  type  should  be,  and  then  to  let  the 
system  tell  you  what  it  thinks  it  should  be  if  it  is  unable  to  coerce  the  one  type  to  the  other 


Creating  a  Module: 


(ledfiielmakejenlSl  vax',  'module.name")  new_vax! 

Amending  a  Module: 

iedtiielmakejenlS1  vax! lmodule_name  Mcduie(  Ro  Ptr.. TlamencLvax'l 
If  the  specification  of  the  module  has  changed  then  it  must  be  change_$peced  as  follows: 

[edlilel  makejeniS!  vax!  |module„name  Module(  RoPlr  )]  chang e_spec_vax! 

N.B  All  other  modules  which  use  the  change_speced  module  must  also  be  recompiled.  (See  later) 
3,2.  PERQ  TO  VAX  TRANSFERS 

Having  created  and  compiled  a  module  on  the  Perq,  the  VAX  code  can  be  transferred  across  to  the 
VAX  for  running  in  the  Tenl5  Evaluation  System 

N  B  The  VAX  should  already  be  running  the  Tenl5  Evaluation  system,  invoked  by  typing 

>  @run_tenl5  simplejoad  tl5  <RETURN> 

>  <R67URN> 

This  sequence  of  commands  can  be  defined  in  the  users  login.com  so  that  a  shorter  command 
such  as  tcnl5  can  be  used  to  invoke  the  Tenl5  system 

i'he  kernel  module  for  the  Tenl5  system  must  then  be  loaded  by  pressing  return  (since 
kernel  mod  is  the  default  module) 

To  transfer  a  module  from  the  Perq  to  the  VAX,  the  following  commands  must  be  obeyed  on  the  two 
machines  with  the  Perq  end  being  obeyed  first 

3.2.1.  On  Perq: 

Apply  send_to_vax  to  the  module  as  follows 

|modu!e_naroe  Module(  RoPtr  )[  send_to_vax* 

N  B  The  transfer  routine  always  fails  on  the  Perq  with  the  error  message  *No  Capability  for 
Creating  Uniques  •  see  PDH",  but  should  be  ignored* 

3  2.2  On  VAX. 

Modules  can  be  transferred  to  the  VAX  by  issuing  the  relevant  commands  from  either  the  true 
(command  line  interpreter)  or  from  the  editor  itself 
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From  True 


Apply  the  procedure  Transfer_module  to  the  name  of  the  Perq  holding  the  required  module  le 
Transfer_moduIe.”perq  name”.  Note  that  procedure  application  is  indicated  by  a  V  on  the  VAX, 
and  that  the  notation  is  forward  polish  rather  than  reverse  polish  as  on  the  Perq 

True  only  has  a  basic  teletype  interface  so  values  created  are  given  names  of  the  form  @0,  @1  etc 
To  use  the  module  it  must  be  loaded  using  Load  which  delivers  the  ro.pointer  to  the  keep  list  of  the 
VAX  module,  then  opened  using  open,  and  finally  named  either  temporarily  using  or 
permanently  in  the  dictionary  using  as  follows 

Input  Transfer_module  tigger” 

@0 

Input  •  Load  @0 
@1 

Input  open@l 
PtrTo  (§>2 

Input  @2  mm  prod 
From  the  editor: 

The  editor  must  first  be  called  from  true  by  obeying  the  command  Load. edit,  or  login. ()  if 
SERCUS  is  to  be  run  as  follows 

Input  Load  edit 
or 

Input  login  () 

Once  in  the  editor  the  command  Trnnsfer_roodule.”pcrq  name”  can  be  evaluated  within  an 
evaluation  box  The  commands  used  to  load  a  module  from  the  editor  are  similar  to  those  issued 
from  true,  except  cartouches  are  used  instead  of  the  @  numbers  The  module  is  loaded  using  Load, 
then  the  pointer  to  the  keep  list  is  dejpointered  using  deptr 

Translerjnodule  "tigger*  ■  m 
deptr  ( Load  m )  --  proc2 

N  B  The  command  line  interpreter  in  the  editor  and  true  use  the  same  dictionary 


3.3  EXECUTING  A  PROCEDURE  ON  THE  VAX 

Having  transferred  a  module  from  the  Perq  to  the  VAX,  loaded  it  into  the  TenlS  Evaluation 
System  and  dejoointered  its  keep  list,  the  procedure  can  be  applied  to  its  parameters 

The  syntax  for  procedure  calls  on  the  VAX  is  procedure.parameter  For  example  proci  takes  void 
le  no  parameters  and  proc2  takes  two  parameters,  thus  to  execute  a  procedure  whose  name  is 
stored  either  temporarily  or  permanently,  type 
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From  True 


Input:  prod  .0 
From  the  editor: 

:  proc2  ( paraml .  param2 ) 

3.4.  OVERVIEW  OF  THE  TEN15 FILESTORE 

The  Tenl5  filestore  is  simply  one  large  VAX  file.  The  implementation  of  the  SEROUS 
demonstration  will  involve  some  manipulation  of  the  Ten  15  filestore,  so  a  brief  overview  of 
terminology  is  provided  here. 

Filestore  values  in  Tenl5  are  accessed  via  filestore  capabilities,  and  these  are  of  two  types: 

X.  Persistent  Values  (persistents) 

2.  Persistent  Variables  (pvurs) 

3.4.1.  Persistent  Values 

These  are  mamstore  values  written  to  filestore  (persisted).  They  can  be  read  (unpersisted)  via 
their  disc  capability,  but  they  cannot  be  assigned  to.  The  operator  Persist  is  used  to  store  a 
representation  of  a  mainstore  value  on  datastore,  returning  a  persistent  value. 

N.B.  Persist  takes  the  datastore  as  a  parameter  as  well. 

While  the  operator  UnPersIst  uses  this  persistent  to  retrieve  a  copy  of  the  value  originally  stored 
on  the  datastore. 

3.4.2.  Persistent  Variables 

These  are  essentially  updateable  references  on  disc  containing  a  persistent  which  can  be 
assigned  to.  (Persistents  may  contain  other  persistents  or  pvars).  The  operator  AssPvar  assigns  a 
persistent  value  to  a  pvar,  and  returns  void.  DcPvar  is  used  to  retrieve  and  deliver  the  persistent 
value  most  recently  assigned  to  a  pvar. 

3.4.3.  Pointer 

A  pointer  points  to  something  in  main  memory.  The  operator  Pack  generates  and  delivers  a 
pointer  to  an  area  of  memory  of  appropriate  size  which  has  been  initialised  to  contain  the  value. 
Conversely  the  operator  D  dejptrs  the  pointer,  returning  the  value  most  recently  assigned  to  it. 

?.4.4.  PSet 


A  Psetisaset  of  Pvars 


SercusModesandOps  is  a  MoModule.  It  contains  all  the  mode,  operator  and  assertion  definitions 
required  for  any  part  of  the  Tenl5  notation  used  in  the  SERCUS  demonstration.  The  mode  and 
operator  names  available  to  a  module  are  all  those  declared  m  the  MoModule,  plus  all  those  that 
occur  in  the  use-lists  defined  in  the  MoModule. 

SercusModesandOps 

)Basic_kafneLr,oc8s :  MoModulel 

Use  Del.  DelVec.  DelSimpfeUn#.  Line 

Operators :  ToEx'isisDelSimpleUne,  ToExistsDelVec 

From|EditLmeMo :  MoModui*] 

Modes: 

“■“<  Described  in  Fo&owing  Sections  — — 

Operators: 

Output  -  402: 

Input  -  403. 

GetTVne  -  407; 

Vdu Message  -  528(5) 

Finish 

Definitions  can  be  used  from  previously  defined  MoModules  by  specifying  a  use-list  of  the  mode 
and  operator  names  that  need  to  be  made  available  from  it  eg.  EditLineMo  above.  If  no  use-list  is 
specified  then  all  the  definitions  in  the  module  will  be  passed  through,  eg.  Basic.kcrnel.modcs 
above.  All  other  modes,  operators  and  assertions  are  then  defined. 

The  MoModule  is  compiled  by  applying  the  procedure  modesandops  to  the  edfile  containing  the 
definitions,  and  then  created  by  applying  the  procedure  ncw.mo- 

I  edfile  j  modesandops!,  •modesjnodule')  newjno! 

If  new  definitions  are  added  to  an  existing  MoModule  then  it  can  simply  be  amended  using 
amend.mo: 

ledlilel  modesandops!  |modes_moduisl  amend_mo!! 

However  if  definitions  are  changed  or  removed  then  the  MoModule  will  have  to  be  change-spaced 
using  chango_spec_mo: 

I  edfile |  modesandops!  1  modes.  . module!  chsnge.specjnoU 


N  B,  All  Modules  using  this  particular  MoModule  will  have  to  be  recompiled  This  is  best  (lone  by 
applying  recompi!e_vax  to  a  top  module. 


The  edfile  containing  the  Ten  15  notation  must  have  a  single  MoModule  at  the  top.  MoModules  are 
the  only  place  where  modes  and  operators  can  be  declared,  and  all  the  inodes  and  operators  in  the 
notation  report,  “A  Notation  for  Ten  15’  Goodenough  and  Rees  (2),  are  automatically  defined  in  the 
MoModule. 

The  MoModule  is  followed  by  Teol5:  and  the  end  of  the  notation  is  indicated  by  Finish.  All 
terminal  symbols  in  the  notation  start  with  a  capital  letter  and  then  continue  in  lower  case.  The 
end  of  a  clause  is  indicated  by  the  key  word  reversed  or  Endkeyword  (where  the  keyword  is 
generally  in  lower  case)  eg. 

H  v  Th*n  w  Eli  x  Then  y  Ets#  z  FI 


Since  a  full  modular  compilation  system  does  not  as  yet  exist,  keep  lists  have  to  be  constructed  by 
hand.  The  operators  Ro  and  Pack  are  used  in  the  last  statement  in  the  module  to  pack  whatever  it 
is  you  wish  to  keep  into  a  read  only  block,  returning  a  pointer  to  this  block,  eg. 

Ro  Peck  ( procl .  proc2.  proc3 ) 

Objects  kept  in  one  module  may  be  used  in  another  by  extracting  them  from  their  defining  module 
using  a  Let  statement  eg. 

Lot  ( procl.  proc2.  proc3 ) •  jtnymodulo  •  Modul<(RoPtr  jj 
Commas  can  be  used  if  the  kept  values  are  to  be  ignored  eg. 
let  ( . , )  -  («nymoduleiMoclute(RoPtf~)| 

N.B.  The  Module  is  automatically  loaded  when  it  is  encountered  in  the  text,  and  the  keeps 
extracted. 

Identifiers  and  variables  defined  within  declarative  statements  (ie.  Let  and  Va r  statements),  are 
only  in  scope  between  the  following  In..Nl*.  Declarative  statements  can  also  be  used  to  declare  the 
type  of  an  identifier  or  variable.  The  translator  compares  the  user  defined  type  with  the  actual  type 
the  object  should  have.  The  editor  is  called  on  the  Perq  allowing  the  user  to  examine  the  modes 
and  discover  the  error  if  the  types  fail  to  match. eg. 

Let  idenirfiert :  Model  •  procl(  identfarl.  idcntlie# ) 

N.B.  Individual  Let  statements  require  no  list  separators,  while  statements  within  the  scope  of  a 
Let  statement  need  to  be  separated  by  semi-colons. 


Getiing  scopes  wrong  can  lead  to  contradictory  error  messages  such  as  ‘’Warning  -  x  declared  and  not  used"  and  “x 
not  dec  brad". 
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The  Ten  15  notation  for  procedures  allows  them  to  be  named  using  a  Let  statement,  and  their  non¬ 
locals  to  be  explicitly  identified  using  a  Use..In  statement  as  follows: 


Let  proci  -  Use  {  non-local  1,  ncrvloca2 )  In 

PfOC(  identifier  1,  identified  :  Mode2 )  •>  Model: 

w...  procedure  body . 

Endproc 

N.B.  There  is  no  closing  Ni  for  the  In  which  identifies  the  non-locals  to  the  procedure. 
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Exceptions  occur  when  for  example  the  user.details  or  trusted  path  flag  cannot  be  extracted  from 
the  context  or  the  cdr  number  supplied  is  out  of  the  range  of  the  registry.  In  such  cases  the 
procedure  where  the  exception  occurred  should  fail. 

The  following  modes  are  defined  for  use  in  handling  exceptions  in  the  code.  Failure  is  a  structure 
of  an  integer  representing  the  failure  number,  and  a  string  representing  the  corresponding 
failure  message.  FailVec  is  a  vector  of  entries  of  type  Failure. 

Falur#  -  struct(  lot  Number,  String  Fa3_Mets } 

FailVec  -  vec{  F*3ure,  Poslnt ) 


A  module,  FailurcNumbers,  is  provided  for  use  by  all  the  other  modules  in  the  SERCUS 
demonstration.  It  contains  a  vector  of  Failure  entries  consisting  of  a  failure  number  and  a 
failure  message  relating  to  the  various  exceptions  that  could  possibly  arise  while  running  the 
demonstration.  These  failure  messages  will  be  used  in  the  diagnosis  of  exceptions  throughout  the 
code.  eg. 

Lot  base :  Int  -  80914 

Let  ctassja.l :  Int «  base  ♦  1 

Let  cla*$_rr#ss ;  String  -  ‘Invalid  Ctassrfcaton* 

Let  dass_detals :  Failure  •  ( efassJaJ,  class  jness )  etc. 

Let  laJ.vec :  FailVec  -  Voc(  7  Oi  dat$_deti2s ) 

In 

fail„yec2  :• . ...ate. 


N.B.  The  base  number  is  a  random  large  number. 

When  an  error  is  detected  in  a  module,  the  operator  Failure  is  used.  This  causes  the  procedure  in 
which  it  was  called  to  fail,  and  an  exception  is  formed  from  the  trap  value.  The  trap  value  is 
generated  by  applying  the  operator  IntToTrap  to  the  appropriate  integer  failure  number  taken 
from  the  module  FailureNumbers. 

Let  (class  Jail. . )  -  | Failure  Numbers  :  Modute(RoPtt .  )1 

In 

Failure  InlToTrapcfassJaJ 


This  exception  can  either  be  caught  in  the  enclosing  procedure,  which  is  usually  the  case,  or 
propagated  on  further  to  be  caught  at  a  later  date. 


The  operator  Trapply  takes  a  procedure  and  it’s  parameters  and  returns  a  union  This  union 
contains  the  result  of  the  procedure  if  it  completed  normally,  the  trap  value  if  an  exception  was 
caused  during  the  execution  of  the  procedure,  or  if  the  procedure  was  jumped  out  of,  a  procedure 
with  which  to  complete  the  long  jump.  (This  third  option  will  not  apply  in  the  SERCUS 
demonstration  code). 
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A  procedure  is  defined  in  the  module  Failure  Numbers  which  takes  the  trap  value  generated  using 
the  operators  IntToTrap  and  Failure  from  the  failure  number  defined  in  FailureNumbers 
corresponding  to  the  nature  of  the  error.  It  returns  the  string  which  diagnoses  the  error,  also 
defined  in  FailureNumbers. 


Ut  fa<_proc  -  Use  ( Ia3vec.  base )  In 
Proc<  faffjrap :  trap )  •>  Siring: 

Let  trap„no :  Im  .  TrapTolnt(  faljrap ) 
Let  fail_.no :  Int  -  trapjio  •  base 
Lo?  details  -  @  ( fa;l_vec  Veclnd  fa3_no ) 
let  message :  String".  FnI^Mess details 
In 

message 

K> 

Endproc 


The  operator  TrapToInt  is  used  to  retrieve  the  failure  reason  from  the  trap  value  ie.  the  value  used 
by  IntToTrap  to  create  the  trap.  The  base  number  is  then  extracted  from  this  number  to  give  the 
index  into  faiLvec.  The  appropriate  diagnostic  message  can  then  be  extracted  from  the  vector 
using  field  extraction. 


This  procedure  is  used  within  Trapply  as  follows: 


let  byebye  -  Ibyabyo  :  ModuletRoPtf..  )| 

Tr  apply{  r»»d_doc .  cdr_num 
I  Op  text:  text 
I  Op  trap: 

(let  mess  -  lail_proc(  trap ) 

In 

message(mess ): 

FaJure  IntToTrap  byebye 
M 

jOpfcmp:JumpO 


N.B,  The  exception  is  propagated  b>  colling  Failure  IntToTrap  on  the  integer  byebye,  a  large 
number  used  to  signify  fatal  errors. 


Error  diagnostics  are  written  to  the  bar  at  the  top  of  the  currently  active  window  using  the 
procedure  message  which  uses  the  system  operator  VduMessage  with  the  appropriate  parameters 
ie.  the  display  and  window  dimensions  and  the  error  message  string. 
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This  module  is  used  to  provide  a  representation  of  document  and  user  classifications  for  the 
SERCUS  demonstration. 

7.1.  MODES  FOR  CLASSIFICATIONS  MODULE 

Tho  classifications  mode  is  defined  as  the  range  of  integers  1..5  as  follows: 

Class  -rang#{  4,1. .5) 

The  4  indicates  that  it  is  an  integer  range,  rather  than  a  character  or  long  integer  range. 

The  classifications  represented  by  the  hierarchy  of  integers  are  : 


1 

unclassified 

2 

restricted 

3 

confidential 

4 

secret 

5 

top  secret 

String  mode  (used  throughout  the  code)  defines  a  string  as  a  read  only  vector  of  characters  with  a 
positive  integer  as  it’s  upper  bound. 

String  -  ro_vec(  Char.  Poslnt ) 

7.2.  PROCEDURES  IN  THE  CLASSIFICATIONS  MODULE 

The  classifications  module  contains  the  procedures  required  to  implement  classifications  in 
Ten  15  notation  for  the  SERCUS  demonstration.  They  are  as  follows : 

7.2.1,  Dominates 

Dominates  is  a  procedure  which  takes  two  parameters  of  type  Class  and  returns  True  if  a  is 
greater  than  or  equal  to  b,  and  False  otherwise  ie.  Unclassified  (1)  is  dominated  by  Restricted  (2) 
since  2  >*  1,  but  Restricted  is  not  dominated  by  Unclassified  since  1  >=  2  is  false.  This  procedure 
is  implemented  using  the  basic  integer  greater  than  or  equal  operator,  >»•. 

Let  dominates  -  Use  ()  In 

Pfoc  ( a.  b :  class )  ■>  Bool. 

a>-b 

Endproc 

7.2.2.  Least 


Least  is  a  procedure  which  takes  two  Class  integers  and  returns  the  lowest  dominating 
classification  in  the  pair,  ie.  given  the  pair  of  classifications  Confidential  13)  and  Unclassified 
(1),  the  lowest  dominating  classification  is  Confidential.  This  procedure  is  implemented  using 


the  basic  operator  Max,  which  delivers  the  maximum  of  two  integers.  Max  is  equivalent  to  the 
construct  “If  a  >  b  Then  a  Else  b  Fi". 


Let  least  *  Use  ()  In 

Proc  <  a.  b :  Class )  •>  Class: 

aWaxb 

Endproc 


7.2.3.  Greatest 


Greatest  is  a  procedure  which  takes  two  Class  integers  and  returns  the  greatest  non  dominating 
classification  in  the  pair,  ie.  given  the  pair  Secret  (4)  and  Restricted  (2),  then  the  greatest  non 
dominating  classification  is  Restricted.  This  procedure  is  implemented  using  the  basic  operator 
Min,  which  delivers  the  minimum  of  two  integers.  Min  is  essentially  equivalent  to  “If  a  <  b  Then 
a  Else  b  Fi*. 

Let  greatest*  Use  0  In 

Proc  <  a.  b :  Class )  •>  Class: 

aM/ib 

Endproc 

7.2.4.  Classjo.str 


Class.to.str  takes  a  Class  integer  and  returns  the  classification  string  which  the  integer 
represents.  For  example  the  integer  1  represents  the  classification  string  Unclassified 

The  following  shows  how  the  vector  of  valid  classifications,  valid.class,  is  constructed.  Firstly 
five  lower  case  strings  corresponding  to  the  five  classification  classes  are  declared. 

ee. 

Let  unctassfied :  String  .  Mncfassifitd* 

Let  restricted :  String  -  ’restricted*  etc. 

Validates*  is  defined  as  a  vector  of  five  elements  of  type  unclassified,  and  then  the  remaining 
four  elements  in  the  .ector  are  set  to  the  other  four  classifications  strings  defined  above.  The 
Tenl5  compilation  system  is  able  to  work  out  automatically  the  replacement  of  strings  in  the 
vector  by  strings  of  different  lengths. 

Ut  vald  class  -  Vec(  5  Of  undassif.ed ) 

In 

vaW.class2  >  restricted;  etc. 

The  procedure  class_to_str  is  implemented  using  vector  indexing  into  the  valid.dass  vector  as 
follows:. 

Let  c!ass_to_su  -  Use  ( vaM_ctass )  In 
Proc  { class :  Class )  ♦>  String 

Let class_str : String  - @  { vaW.c!ass  Veclnd class ) 

In 

c!ass_str 

Mi 

Endproc 
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N.B.  The  operator  ©  is  used  to  dejref  a  reference  or  vector,  returning  the  value  most  recently 
assigned  to  it1. 


7.2.5.  Str_to.cIass 


This  procedure  returns  the  Class  integer  corresponding  to  a  classifications  stnng.  Initially  its 
primary  use  will  be  in  the  testing  of  the  classifications  module,  although  it  will  also  be  used  to 
assign  clearances  to  users.  It  will  eventually  be  used  in  the  creation  and  regrading  of  documents 
which  require  the  user  to  be  prompted  to  enter  a  classification. 


The  first  implementation  of  str.to.dass  used  an  If».Then..EUf..Fi  statement  to  recognise  the 
classification  string  as  a  whole  eg.  Unclassified,  or  the  first  letter  of  the  string  eg,  U,  to  facilitate 
the  return  of  the  correct  class.  This  implementation  was  by  no  means  ideal.  A  better 
implementation  of  str_to„dass  was  found  which  involved  converting  the  given  string  to  upper 
case  characters,  so  that  it  is  not  case  sensitive,  and  then  matching  it  against  the  classifications 
strings  held  in  the  valid.dast  vector,  which  are  also  converted  to  upper  case. 


Let tojjpper  -  |to_uppor ;  Modulef  RoPtr,. )} 

Lot  ( dassJaitZI)  » |Faihjtd?umb*rs  *~Mo~ctufo(  RoPtr..  )| 

Lot  strjo_cliss  -  Us#(  va!ri_dass.  to.ypper,  class Jal )  In 
Proc  ( str :  String )  .>  Class: 

Let  upb :  Poslnt  -  Upb  str 

Lai  naw_str :  Siring  -  to_upp«r(  sir ) 

Var  I :  ref  Poslnt  >  0 
In 

For  n  To  Upb  vaEd jcla  ss  WhJa  @1-0 
Do 

Lat  cte*s„str :  String  -  @  { vaSd.dass  Veclnd  n ) 

Lat  compare :  String  -  to_upp*r(  dass_str ) 

Lat  trimmed :  String  -  compare  Trim!*  upb 
In 

K  trimmed  VecEq  naw_*tf 
Then 
I*-  n 
R 
ffi 
Od; 

K@«-0 

Then 

Failure  IntToTr  ap  dassjail 
Else 

CrClass  @1 
R 
tb 

Endproc 

The  idea  of  the  procedure  is  to  take  a  classifications  string,  convert  it  to  upper  case  characters  and 
find  its  length,  say  upb.  Before  comparison,  each  string  in  the  valid_da$s  vector  is  trimmed  to 
upb  characters  using  the  vector  operation  Trimle  (Trim  when  less  than  or  equal  to  upb).  The 
string  is  then  compared  with  the  first  upb  characters  of  the  upper  case  conversion  of  each  string  in 
the  vahdLclass  vector,  using  a  For..To..While..Do..Od  loop  to  index  the  vector  until  a  match  is 


@  without  a  space  is  used  for  labels  eg.  @Iabel.  When  @  is  used  to  de*ref  an  object,  care  must  be  taken  to  ensure 
a  space  is  inserted  as  this  is  a  very  difficult  error  to  spot. 
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found,  if  one  exists.  The  Class  represented  by  the  stnng  is  returned,  and  this  corresponds  to  the 
index  into  the  vector  which  provided  the  match.  This  Class  must  be  changed  ranged  using  the 
operator  CrClass  which  takes  an  operand  and  converts  it  into  a  value  with  type  Class,  so  that  the 
value  returned  will  actually  be  in  the  range  1..5,  eg.  1  is  given  range  1..1. 

If  no  match  is  found  then  the  procedure  will  fail  using  the  Failure  operation  which  forms  an 
exception  from  the  trap  value.  The  operation  IntToTrap  is  used  to  create  the  trap  value  from  the 
integer  class.fail.  Classjail  is  defined  in  the  FailureNumbers  module  along  with  an 
appropriate  error  message.  All  other  failure  numbers  and  messages  are  also  defined  in  this 
module.  The  exception  can  be  'caught'  in  an  enclosing  procedure  using  Trapply. 

This  implementation  of  str_to_das$  is  much  more  versatile  since  any  shortening  of  the 
classification  classes,  ranging  from  the  initial  letter  to  the  whole  word  will  be  recognised. 

7.3.  TESTING  THE  CLASSIFICATIONS  MODULE 

Unfortunately  in  the  cross  compilation  system  at  present  there  is  no  capability  to  examine 
structures  in  the  Ten  15  editor  in  order  to  extract  procedures  etc.  for  test  purposes.  Thus  the 
classifications  module  was  not  sent  directly  to  the  VAX,  but  instead  five  test  procedures  were 
written  in  separate  modules  to  test  each  of  the  five  classification  procedures,  and  these  were  sent 
separately. 

The  test  procedures  for  dominates,  least,  greatest,  and  cla$sJo..str  require  Class  integers  a» 
parameters.  The  procedure  str_to_class  must  therefore  be  applied  to  some  classifications  strings 
so  as  to  produce  Class  integers  for  use  in  the  test  procedures. 

str_to_cl«s,*Unctass<ied*  -  u  etc. 

This  will  give  for  example,  the  string  “Unclassified*  the  classification  I,  and  name  it  u.  Some 
examples  of  testing  the  classifications  procedures  are: 

do/nmat«s.(  s.  u ) 

l«*si.(  u,  c ) 

greatest  (r.t) 

dassjo_str.(  s ) 

7.4.  GENERAL  COMMENTS 

The  classifications  module  as  specified  above  forms  an  abstract  data  type  (ADT)  representing  the 
classifications  system  used  in  the  SGRCUS  demonstration.  Thus  assuming  the  required 
operations  on  classes  remain  unchanged,  the  implementation  of  the  procedures  can  be  altered  or 
amended  with  no  affect  on  the  use  of  classifications  in  the  demonstration 

N.B.  All  modules  using  the  classifications  module  will  need  to  be  recompiled,  this  can  be  done 
using  the  procedure  recompile_vax. 


S^CO\TFVTMpnnF 


; t ^™tz7ss!ne  trents  and  j'ouma,s  must  te  - 

information,  is  ^  «•  «*  other 

Jocal  to  the  procedures.  The  names  of  the  fthi  «».  .M  ^  4ntn€s  from  a  list  kept  non- 

8.1.  MODES  FOR  CONTEXT  MODULE 

something oftha/mode.  l^iymorphlc^jes^rerepreMntedhj^thefoiTOS  ** 

Ent^  -  3  ( X :  $truct(  ptr  X,  unJpu#  X )  )> 

Context  mode  is  defined  as  a  vector  of  polymorphic  entries  as  follows: 

Coolest .  vsc  |  Entry,  Postal ) 

g?s®wsarjh» 

>  <  ^mmy_vaKe..  dumroy_k.y , 

includes  a  coding  of  Z mac  'on  whmh Tw  “*  T"  « '*  *»  —  *. 

Unique  Y.  then  since  .ll  cll  l  fe  ,™  ~<A  "  *  "Cy  is  k"°™  «•  have  type 
basis  behind  the  assertion  Match  which  ^,^1*  tS"***  'hM  *  '  and  thl!  is  tf" 
and  delivers  a  pointer  to  an  area  d  ll  lu  f  'be ™dul'- Pack  ««wt.s 
value  l.ToExists  takes  the  ooerand  !.  u7*  'c>l  hss  bttn  initialised  to  contain  the  integer 
but  withits  type  generalised  to  the  a"d  d‘'iV‘rS  " 

8.2.  procedures  in  the  context  module 


fhe  context  module  contains  the  procedures  required  to  imp), 
notation  for  the  SERCVS  demonstration.  They  are  as  follows : 


$•2.1.  Set_context 


J 


Set.context  is  a  polymorphic  procedure  taking 
adding  them  to  the  context  Set.context  has  the 


a  key  and  its  corresponding  pointer  value  and 
context  vector  as  a  non-local  variable,  and  the 


Vetoing  the  polymorphic  structure  the 
cause  the  assertion  Match  to  fad 


more  naiura!  way  round  with  the  umque  followed  by  the  potatcr,  w.ll 
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procedure  returns  void.  If  the  key  already  exists  then  the  existing  value  is  overwritten  with  the 
new  value.  A  polymorphic  procedure  can  be  recognised  by  a  definition  of  the  form  Proc  Formal*  X 
etc.  as  below: 


Proc  Formate  X  ( key :  unique  X,  value :  ptr  X )  •>  void: 


Let  set.context  -  Use  ( context )  In 

Proc  Formal*  X  ( key :  unique  X.  value :  ptr  X )  •>  void: 

let  new.entry :  Entry  -  ToExtsts :  $truct(  Enty,  X )  ( value,  key ) 
In 

For  ft  To  Upb  ©  context 
Repeat  ©again: 

Match{  ©  ( @  context  Veclnd  n ),  key 
1  ©  context  Veclnd  n  >  new.entry 
j  Goto  ©again} 

Giving 

Let  new :  Context  -  Vec(  1  Of  new.entry ) 

In 

context :-  new  Concat  ©  context 
Ni 

Endfor 

Ni 

Endproc 


The  key  and  value  are  first  converted  to  the  correct  mode  for  insertion  into  the  context  vector  (ie 
the  polymorphic  type  Entry),  using  the  polymorphic  operator  ToExists. 

A  Repeat  ..Giving  loop  is  then  used  to  run  through  the  entries  in  the  context  vector  looking  for  a 
match  with  the  procedure  key.  The  match  is  done  using  the  assertion  Match  which  tests  the 
polymorphic  operand  to  determine  whether  the  unique  component  of  the  structure  matches  the  key 
If  the  uniques  are  equal  then  their  types  are  also  equal  and  the  match  is  obeyed  with  the  other 
component  of  the  structure  as  argument.  In  this  case  the  matching  entry  in  the  context  is 
overwritten  with  the  new  entry,  and  the  loop  is  exited.  If  the  key  does  not  match,  the  loop  is 
repeated. 

If  after  examination  of  the  whole  context  vector  a  match  is  still  not  found  then  the  Giving  part  of 
the  loop  construct  is  executed.  This  involves  forming  a  new  vector  of  mode  Context  with  one  entry 
ie.  new.entry,  and  then  concatenating  this  new  vector  on  to  the  existing  context  vector  to  give  the 
new  context. 


8.2.2.  Zap.context 


Zap.context  is  a  polymorphic  procedure  which  takes  a  unique  key  as  parameter  and  finds  the 
corresponding  entry  in  the  context,  which  is  then  removed.  Zap.context  has  the  context  vector  as  a 
non-local  variable,  and  the  procedure  returns  void.  If  there  is  no  entry  corresponding  to  the  key, 
then  the  procedure  fails. 

Proc  Formal*  X  ( k«y :  unique  X )  •>  void: 

Let  zap.context  -  Use  ( context,  contextJaJ)  In 
"Proc  Formate  x  { key :  unique  X )  •>  void 
For  n  To  Upb  ©context 
Repeat  ©again: 

Match  { ©  { ©context  Veclnd  ft ).  key 
|  Let  below :  Context  •  ©  context  Turn!  n 
Let  above :  Context  -  ©  context  Tnmg  n 
In 


context  below  Concat  above 


f£ 

|  Goto  ©again} 

Giving 

Fa^jre  IntToTrap  contextjail 
Endfor 
Endproc 


A  Repeat-Giving  loop  is  used  to  run  through  the  context  vector  to  find  the  entry  with  the  parameter 
key.  Once  this  entry  has  been  identified  it  is  removed  by  trimming  the  vector  entries  below  this 
particular  entry  with  the  operator  Triml,  and  trimming  those  above  using  the  operator  Trimg. 
The  new  context  vector  is  formed  by  concatenating  these  two  trimmed  vectors  together,  the  loop 
then  terminates. 


If  ths  key  does  not  match,  then  the  loop  is  repeated  until  a  match  is  found.  If  no  matching  entry  is 
located  then  the  procedure  will  fail  with  the  exception  being  created  from  the  integer  context_fail 
defined  in  the  module  FailureNumbers.  This  exception  can  be  trapped  using  Trapply  in  an 
enclosing  procedure. 


8.2.3.  CeLcontext 


Get.context  is  a  polymorphic  procedure  which  takes  a  unique  key,  checks  that  it  is  m  the  context, 
and  then  returns  the  value  corresponding  to  the  key,  otherwise  it  fails. 


Proc  Forma!*  X ( key :  unique  x )  •>  union  ( ptr  X.  vod ) 

Let  gat_context  -  Us®  ( context )  In 

Pro c  Forma!*  X  ( key :  unique  X )  •>  ptr  X- 
For  n  To  Upb  ©context 
Repeat  ©agan : 

Match  ( ©  ( ©  context  Veclnd  n ).  key 
|  Op  vakie:  Unite  1  vafue 
|  Goto  ©again} 

Giving 

F*3ur®  IntToTrap  contoxtJaH 
Endfor 
Endproc 


The  context  vector  is  examined  one  entry  at  a  time  using  a  Rcpcat..Giving  loop,  and  the  assertion 
Match.  If  an  entry  is  found  matching  the  key,  then  the  pointer  to  the  corresponding  value  is 
returned  and  the  loop  terminates.  If  no  match  is  found,  thcr.  the  procedure  fails  with  the  exception 
being  generated  from  the  integer  contextjail. 


8.3.  TESTING  THE  CONTEXT  MODULE 

Before  the  context  module  can  be  tested  some  uniques  must  first  be  generated. 

8.3.1.  Generating  Uniques 

Unique  keys  are  generated  using  the  following  piece  of  Tenl5  notation  contained  in  an  edfile 

Define  te$t_key  -  Make  Unique  type() 

Keep  testjkoy 

MakeUnique  (type)  generates  and  delivers  a  unique  value  of  type  Unique  type. 
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To  actually  generate  a  unique  the  procedures  compile_tenl5  and  run,tenl5  must  be  applied  to  the 
edfile  as  follows: 

jedlitet  compile Jen15'/unjeri15l 

8.3.2.  Context  Jestl 

Three  unique  integer  keys  were  generated  by  compiling  and  running  the  above  edfile  with  type 
defined  as  integer.  An  integer  value  was  then  associated  with  each  of  the  unique  keys  generated. 
This  test  procedure  takes  a  void  as  parameter  and  returns  void. 

Keys  are  set  by  calling  the  procedure  $et_context  with  a  unique  key  and  a  pointer  to  the  integer 
value  eg. 

set(  keyl.  Pack  valuet ) 

Keys  are  removed  by  calling  the  procedure  zap.context  from  the  context  module  with  a  unique  key 
as  parameter,  from  within  Trapply  eg. 

Trappfy(  rap.  key! 

|  Op  context :  () 

I  Output  *No  Match" 

|OpjMmp:jump{) 

If  zap^context  is  successful  then  void  is  returned,  if  no  match  is  found  for  the  key  then  the 
message  "No  Match"  is  output. 

The  value  associated  with  a  given  key  is  retrieved  using  the  procedure  get.context  within  a 
Trapply. 

Trapp>y{  get,  key! 

J  Op  context :  ptr  X 
Output  "Not  Found* 

|Opkimp:kirr.p{) 

) 

If  get^context  is  successful  the  a  ptr  to  the  value  corresponding  to  the  key  is  returned.  If  the 
procedure  fails  then  the  message  "Not  Found"  is  output. 


Document  journals  are  used  to  record  the  events  that  happen  m  the  life  of  a  document.  User 
journals  are  used  to  record  the  actions  earned  out  by  a  particular  user  eg.  login  and  logout  etc.  A 
document  Journal  is  protected  from  arbitrary  access  by  making  it  non*local  to  the  read  and 
review  procedures  and  not  exporting  it  from  the  module.  The  users  journal  is  protected  from 
arbitrary  access  by  setting  it  in  the  context  so  allowing  only  a  trusted  procedure  holding  the  key  to 
recover  it. 

9.1.  MODES  FOR  THE  JOURNALLING  MODULE 

Both  document  and  user  journals  are  implemented  as  persistent  variables  (pvars)  containing  a 
linked  list  of  events.  Modes  required  for  the  implementation  of  journals  are  defined  in 
SercusModcsandOps  and  are  as  follows: 

cycle  ( Event  -  structf  String  Who  What  Date,  choce  ptr  pers  Event  Last ) ) 

Journal «  pvar  Event 

Event  is  a  structure  of  three  strings,  Who,  What,  Date,  and  a  choice  ptr  pers  Event.  The  names  of 
the  three  strings  are  used  as  operators  to  select  the  fields  from  the  structure  eg 

Let  name :  Stnng  -  Who  event 

The  choice  ptr  pers  Event  is  effectively  a  pointer  to  the  previous  entry  in  the  linked  list.  It  is 
defined  as  a  choice  ptr  so  as  to  allow  the  previous  event  to  be  null  if  the  end  of  the  list  has  been 
reached. 

9.2.  PROCEDURES  IN  THE  JOURNALLING  MODULE 

The  journalling  module  contains  the  procedures  required  to  implement  the  user  and  document 
journals  in  Tenl5  notation  for  the  SERCUS  demonstration.  They  are  as  follows. 

9.2.1.  Add  Journal 

Addjournal  takes  as  parameters  three  strings,  who,  what  and  date  and  adds  them  to  the  journal 
(also  supplied  as  a  parameter),  the  procedure  returns  void.  Datastore  is  supplied  to  the  procedure 
as  a  non-local. 

Let  add  Journal  •  Use  ( datssrore )  tn 

Proc  { journal :  Journal,  who.  what,  date :  Stnng )  •>  vod 
Let  j :  pers  Event  •  DePvar  journal 
Let  c :  cho^e  ptr  pers  Event  -  ToChoce  Pack  j 
Let  new_event :  Event  -  { who.  what,  date,  c ) 

Let  new .  pers  Event  -  Persist  { new_event,  datastore } 

In 

journal  Ass  Pvar  new 
Hi 

Endproc 


Add  journal  retrieves  and  delivers  the  pers  Event  most  recently  assigned  to  the  pvar  le.  the  last 
event  in  the  journal.  This  pers  Event  is  turned  into  a  choice  ptr  pers  Event1  by  first  applying  Pack 
which  generates  and  delivers  a  pointer,  followed  by  ToChoice  which  converts  the  operand  into  the 
corresponding  non-null  choice.  A  new  event  is  defined  as  being  a  struct  of  the  three  parameter 
strings  and  the  newly  formed  choice  ptr  pers  Event  This  new  event  is  then  stored  on  the  datastore 
using  the  operation  Persist,  and  returning  a  persistent  value  which  is  assigned  to  the  pvar  journal 
using  As* Pvar. 

9.2.2.  Reviewjounul 

Reviewjoumal  takes  a  journal  and  displays  its  contents  as  an  editable  vertical  (vector  of 
strings).  Reviewjoumal  uses  the  procedure  display.event  defined  as  follows: 


let  blank  -  ToEx»tsDelSimp!eUne(  Pack  AsUno'  del_S)mp!eJ'mejj ) 

Let  disptay_event  -  Us#  { Wank.  del.slmple Jfoe„u )  In 
Proc  ( ev#nt :  Event )  *>  DelVec: 

L#t  whatstr :  String  -  *Ev#nt:  *  Concat  What  «v#nt 

lot  whostr . . 

Ut  whenstr....... 

L#t  whatlm#  -  ToExi*!$DelSimpleltne(  Pack  As  line  whatstr.  del_stmpleJmejj ) 

Let  whot*n# . 

Let  whanlne,. ...... 

Let  vertical  -  AsDelVec  Vec<  4  01  AsOel  Whattme ) 

In 

vertcal2 whoSne: 
vertealj  :•  whenlne; 
vertcal4  >  blank, 
vertical 
Ni 

Endproc 


Display.event  takes  an  event,  extracts  the  strings  using  the  names  as  field  extraction  operators, 
and  turns  them  into  simple  line  uniques  using  ToExi*.  sDelSimpIcLinc.  A  vertical  vector  is  then 
formed  from  the  lines  using  AsDolVcc,  and  returned. 


Reviewjoumal  takes  a  journal  as  parameter  and  returns  a  Del.  It  takes  as  non-locals  the 
procedure  display.event  and  del.vert.u,  a  procedure  for  creating  uniques  for  verticals.  It  is 
defined  as  follows: 


Proc  review Journal  •  ( journal :  Journal )  •>  Del: 

Let  reviewjoumal  -  Uso  ( displace  vent.  del_vert_u )  In 
Proc  ( journal :  Journal )  *>  Del 

Let  pe :  pers  Event  >  OePvar  journal 
Let  lust :  Event  -  UnPersist  p« 

Var  vertical :  rel  DelVec display_ev#nt(  first ) 
Var  next :  re!  cho«e  ptr  pers  Event Last  tost 
In 

Loop  ©label : 

NotVoid  { ©next 
|Opp 

Let  event  Event  -  UnPersist  D  p 


A  choice  pers  Event  was  really  what  was  required  here,  but  supnsinjy  the  system  would  not  allow  this  Thus  a 
ptr  pers  Event  was  used  instead  which  could  be  choiced1  When  the  system  is  improved,  the  pointer  aspect  will  be 
removed. 
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In 

Vertca!  •-  display_#v«nt(  «v«nt )  Concat  @  vertea!; 
next  >  last  event; 

Goto  @tab«t 

ff 

10} 

End  loop; 

ToExi$?sDe!V*c(  Pack  (^vertical.  del_vert  u ) 

Ni 

Endproc 

First  the  pers  Event  most  recently  assigned  to  the  journal  is  extracted  using  the  operator  DePvar, 
and  unpersisted.  This  unpersisted  event  is  passed  to  the  display_event  procedure,  and  the  next 
event  in  the  linked  list  is  referenced.  The  procedure  then  enters  a  loop  to  extract  and  display  the 
remaining  events  in  the  linked  list.  The  loop  is  constructed  using  the  NotVoid  assertion  which 
tests  the  choice  ptr  pers  Event  ie  the  next  Event  m  the  list.  If  this  is  not  null  then  the  operator 
nonvoid  is  obeyed  with  the  next  Event  as  argument.  The  operator  takes  the  ptr  pers  Event  and 
retrieves  the  previous  Event  using  the  operators  Unpersist  and  D  (de.ptrs  a  pointer).  This  event  is 
then  passed  to  the  display.event  procedure,  with  the  DelVec  returned  being  concatenated  onto  the 
vertical  vector.  The  loop  is  repeated  until  the  null  choice  is  reached  and  the  operator  null  is  obeyed 
with  argument  void.  Finally  the  vertical  vector  is  converted  into  a  Del  using  ToExistsDelVec. 

9.2.3.  Createjoumal 

Before  the  procedures  can  be  tested  a  journal  has  to  be  created.  The  procedure  createjoumal  takes 
two  strings,  one  the  user's  name  and  the  other  the  nature  of  the  action,  and  returns  a  journal. 

let  da:a$:or#  -  |  datastore :  Module(RoPM) 
let  rootjiset  -  |roct_ps«t :  Modult(RoPtr..)l 
let  ( ,  date,  time)  •  (dato  Tndjtme  ;  Moduie(RoPlr  ))> 

let  createjoumal  -  Use  <  datastore,  root_p$et.  date,  time )  In 
Proc  ( whal_str,  who_str :  String )  •>  Journal. 

let  e :  choice  ptr” pers  Event •  Nu3 :  ptr  pers  Event!) 

let  inn  event :  Event • ( who_stf,  wh*t_str,  <§>  date  Concat  tune!),  e ) 

let  imtialjiers :  pers  Event  -'Persist  { ma^event.  datastore } 

In 

CreatePvarJ  root^pset.  intialjiers ) 

Ni 

Endproc 

An  initial  event  describing  the  creation  of  a  journal  is  formed  using  the  who  and  what  strings 
and  the  date  and  time  from  the  date_and_time  module,  with  the  pointer  to  the  previous  event  being 
a  null  choice  of  type  ptr  pers  Event  generated  using  the  operator  Null.  This  initial  event  is  then 
persisted  to  the  datastore,  and  a  journal  is  created  using  CrcatePvar  to  deliver  a  new  pvar  with 
parent  root_pset.  Finally  journal  1$  initialised  to  contain  the  pers  Event  initiate  vent. 


The  system  operator  GetTime  gives  the  number  of  seconds  past  midnight,  but  no  date.  Thus  the  date  is  input  as  a 
string  at  the  start  of  the  demo. 
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9.3.  TESTING  THE  JOURNALLING  MODULE 


The  procedure  joumal_testl  tests  both  the  add  journal  and  review  journal  procedures. 

9.3.1.  Journaljcstl 

Joumal_testl  is  a  procedure  which  takes  void  and  delivers  a  persist  Del. 

Events  are  added  to  the  journal  using  the  add  procedure  defined  in  the  journalling  module,  „nd 
reviewed  using  the  review  procedure.  Review  returns  a  Del,  but  since  the  test  procedure  requires 
that  a  persist  Del  is  returned,  the  result  of  review  is  persisted  to  the  datastore. 
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10.,  LOGIN  AND,  RELATED  PROCEDURES 


The  following  procedures  allow  a  user  to  login  to  the  Tenl5  editor.  Once  in  the  editor,  the  system 
can  be  asked  to  answer  questions  and  perfomVsimulate  operations,  these  form  the  basis  of  the 
SEROUS  demonstration.  The  questions  include  Who  am  1?  (who),  What's  my  clearance?  (what), 
and  Am  I  on  the  trusted  path?  (where),  while  the  operations  include  Review  my  journal 
(myjoumal),  Put  me  on  the  trusted  path  (on.tojp)  and  Take  me  off  the  trusted  path  (off.tp).  All 
the  above  are  written  as  ions.  An  ion  is  very  similar  to  a  procedure  except  that  some  of  the  non* 
locals  are  not  given  values  in  the  construct,  only  a  specification,  with  the  actual  values  being 
supplied  at  a  later  time.  These  specifications  have  the  same  form  as  parameters. 

10.1.  MODES  REQUIRED  FOR  THE  LOGIN  RELATED  PROCEDURES 

The  following  modes  are  defined  for  use  in  the  login  related  ions  and  procedures: 

User  mode  is  defined  as  a  structure  of  two  strings  representing  the  user's  id  and  password  and  a 
Class  corresponding  to  the  user's  clearance. 

User  -  struct(  String  U*d  Password,  Class  Clearance ) 

ValidUsers  is  defined  as  a  vector  of  entries  of  mode  User  as  follows: 

VaW Users  -  vec<  User,  Poslnt ) 

UserDetails  is  a  structure  of  a  string  representing  the  users  id,  a  Class  representing  the  user's 
clearance  and  a  Journal  representing  the  user's  journal. 

UserDetails  •  struct(  String  Udjd,  Class  Ud.Clear,  Journal  Ud_Journal ) 

N.B,  The  modes  User  and  UserDetails  will  eventually  be  expanded  to  include  a  users  cupboard 
and  mail  box. 

The  TpFlag  allows  the  user  to  determine  whether  they  are  on  or  off  the  trusted  path.  However,  the 
actions  of  going  on  to,  or  off  the  trusted  path  are  only  simulated  at  present  The  TpFlag  is  defined 
as  a  bool  value  as  follows: 


TpTlag-bcot 


10.2.  JONS  AND  PROCEDURES  RELATED  TO  LOGIN 


10,2.1.  Login  Ion 

This  module  declares  an  ion  for  login  which  when  closed  with  the  uniques  for  user  details  and 

trusted  path  flag,  the  va!id_users  vector  and  journal  becomes  apr.cedure'oftype^void  to  void'  * 

Let  (sol,)  -  Iconloxl :  ModulofRnPir  il 
Lot  (add,) .  |  journal :  ModulefltoPii..  il 
Lot  (.date, tine) .  (gate  and  mil ) 

lot  stringlongth :  Poslnt  •  C1P0sl.1t  10 
in 

Ro  Pack  Use  ( stnojlength,  sot,  add.  date,  time )  In 
•on  ( user^detaJs :  unique  lIserDetaJs ) 

( tpflag :  unique  TpFlag  > 

(vaGdjjserszVaWUsers) 

(journal;  Journal) 

Void  •>  Void; 

loop  ©next: 

Output  ’Please  Enter  Your  Nam*'; 

Let  *vec1  Vec{  stringlengtn  Oi  CrChar’  *) 

Let  usd :  String  -  Input  invecl 

lot paSd'PSgT^’’^^^' V,C< WClCh.,-)) 

In 

Foral  uj«r  in  valid  users 
Repeat  ©agam: 

»( Ud  ©  usot  VocEq  ud )  Andth  ( Posswoid  <S>  user  VocEq  possmid ) 

lot  odd  *.  fclh  .odd  t  ModulolRoPlr.. )) 

L«>  clear  ance  "class  .  Clearance®  usoi 
l!!  :  UsoiDotails  » ( ud,  clearance.  | pumal ) 

Let  flag :  TpFlag  •  True 
In 

add(  journal,  u>d.  ’Logged  in’,  @  date  Concat  time{) ); 
set(  user.details.  Pack  detals ): 
set{  tpflag.  Pack  Hag ); 

TrappJy(  edit.  () 

(Failure  IntToTrap  11 
I  Output  ( •  8ye  By*  •  Concat  uxj ); 

Goto  U<1' ’l05s*Ii C“'-' ®  Ccnci’ ,m,<> )•' 

|Op)jmp:jump() 

ti  1 

Else 

Goto  ©again 
Fi 

Giving 

Output  ’Authorisation  Failure’ 

Endfor 

Ni 

Endloop 

Endon 


Login  ts  essentially  a  loop,  which  prompts  for  a  user  name  followed  by  a  password  (Tha  name  or 

matchT!  ‘S  "*  f ‘CT  chamt"s  > The  vector  of  valid.users  is  then  examined  for  a 
match  on  the  user  name  and  the  password.  If  tha  match  ,s  successful,  then  the  users  ID,  the  event 
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“Logged  in",  and  the  date  and  time  are  added  to  the  user’s  journal.  Additionally  the  user_details 
(uid,  clearance  and  journal)  and  tpflag  (set  to  true)  are  set  in  the  context. 

Login  then  calls  the  editor  using  the  operator  Trapply,  Trapply  calls  the  editing  procedure  edit 
with  the  required  void  parameter,  and  tests  the  exit  status  of  the  procedure  call.  If  the  procedure 
completes  normally  then  Failure  IntToTrap  11  is  obeyed.  (This  will  never  happen  in  practice )  It 
should  also  be  noted  that  the  only  way  to  leave  the  editor  is  to  malte  it  fail  ie.  the  editor  is 
successfully  exited  when  it  is  allowed  to  fail.  If  the  procedure  fails  (the  only  case  that  will  apply 
with  edit)  then  the  logout  message  is  output,  the  appropriate  “Logged  out"  message  and  date  and 
time  are  added  to  the  user’s  journal,  and  the  procedure  again  prompts  for  a  user  name  to  be  input. 
The  third  alternative  in  the  Trapply  is  for  a  long  jump  out  of  the  procedure,  but  as  this  will  never 
happen  it  can  be  ignored  in  the  documentation. 

If  the  user  name  was  not  found  in  the  vector  of  validjisers,  or  the  passwords  did  not  match  then 
the  procedure  outputs  an  authorisation  failure  message  and  dies.  This  is  sufficient  for  the 
moment,  but  eventually  it  should  prompt  for  a  new  user  name  after  an  authorisation  failure 
instead  of  requiring  that  the  login  procedure  is  called  again. 

10.2.2,  Login  Procedure 

The  ion  for  login  can  be  closed  with  the  following  non-local  values,  the  unique  for  user  details,  the 
unique  for  the  trusted  path  flag,  the  vector  of  valid  users,  and  the  user’s  journal.  Once  each  ion 
has  been  closed,  login  becomes  a  procedure  of  type  void  to  void  ie. 

»n(  unique  User  Detafc.  ton(  unique  TpFlag.  »n(  VaWUsers.  »n(  Journal,  Void  •>  Void )))) 

Proc  login  -  ()  •>  0: 

Two  uniques  are  generated  as  described  previously,  unique.ud  is  a  unique  for  the  UserDetails, 
and  unique.tp  is  a  unique  for  the  TpFlag. 

Let  unique_ud : unique  UserOetais  - 1  A  :  Unique  ( .)  | 

Let  unique Jp :  uruque  TpFlag  •  |  A  :  Unique  Bool) 

A  journal  is  also  created  using  the  procedure  createjournal. 

Let  journal :  Journal  -  createjournal  'Journal  Created'.  'Administrator* ) 

Sets  of  user  details  are  formed  as  a  structure  of  the  three  strings  representing  user  ID,  password 
and  clearance  ( the  procedure  class.to.str  is  used  to  convert  a  Class  into  a  String).  A  vector  of 
valid  users  is  formed  from  the  sets  of  user  details. 

The  login  ion  is  then  closed  as  follows  to  give  a  procedure  taking  void  and  returning  void 

Let  closed! :  «on(  unique  TpFlag,  en(  VaWUsers,  en(  Journal,  Void  •>  Void ) ) ) 

•  un«qu#_od  Close  logmjon 

Let  dosed2 :  »n(  VaWUsers.  on{  Journal.  Void  •>  Void ) ) «  umquejp  Close  dosedt 
Let  closed3 :  ion(  Journal.  Void  *>  Void )  -  va&djjsers  Close  dosed2 
Let  logn  *  Void  •>  Void  •  journal  Close  ctosed3 
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10.2  J,  Who  Am  I  Ion 


When  closed  to  form  a  procedure,  this  ion  will  determine  who  is  logged  in  to  the  system. 

Let  (..get)  -  (context ;  Module (RoPinT)] 

Let  ( . ,fail_proc)  -  |FailuroNumbets  :  Madule{RoPlr..“)) 

Let  byebye  -  [byebye  :  Madule(RoPtr..")| 

Let  message  - )  Message  :  Modu!e(RoPtr.,  )| 


In 

Ro  Pack  Use  { get.  faUjiroc.  byebye,  message )  In 
bn  ( u$er_deta2s ;  unique  UserDetaJs ) 

Void  •>  String: 

Trapplyl  get.  user_details 
|  Op  ptrjJetails: 

Let  detaits :  UserDetaZs  -  0  ptrjdetails 
Let  me :  String  -  Udjd  details 
In 


Endion 


me 


Hi 

|  Op  trap* 

Let  mess  •  failj>roc<  trap ) 
In 


me$sage{  mess  Concat  * :  Pancll  No  User  Details  tn  Context* ); 
Ftrfure  ImToTrap  byebye 
Ni 

jOpfjmptjjmpO 


WhoAml  ion  is  based  on  the  operator  Trapply.  Get.context  is  used  to  extract  the  user.details  from 
the  context.  If  successful,  get  returns  a  pointer  to  the  user.details  which  is  de-ptred  using  D  to  get 
the  user_details.  The  users  User  ID  is  then  extracted  from  the  structure  and  returned, 

If  get  fails  to  find  the  u$er_details  in  the  context  then  the  procedure  will  fail  using  the  operator 
Failure  which  forms  an  exception  from  the  trap  value  created  from  the  integer  contextjail 
defined  in  the  FailureNumbers  module. 

The  other  ions  described  in  this  section  are  generally  constructed  in  a  manner  very  similar  to 
that  of  the  WhoAml  ion,  using  the  operator  Trapply. 

10.2.4.  Who  Am  I  Procedure 

The  WhoAml  ion  is  closed  with  the  unique  for  user  details  to  give  a  procedure  that  takes  void  and 
returns  a  string. 

lon{  unique  UserDetails,  Void  •>  String ) 

N.B,  The  same  unique  generated  for  the  unique  user  details  in  login  must  be  used  to  close  the 
WhoAml  ion 

Let  whoami ;  Void  _>  String  »  unique_ud  Close  whoamijon 


10.2.5.  Whats  My  Clearance  Ion 


When  closed  this  ion  will  allow  the  clearance  of  the  user  to  be  determined. 


Us  („.c!a$sjo_$tr)  -  [classifications :  Modulo(RoPtr.. )) 

Ut  {..got)  -  [ context ;  Module(RoPtr7)] 

Let  ( . ,failj>roc)  •  [Failure  Numbers ;  Module(RoPtf.r)j 

Let byebye  -  [byebye  :  Module(RoPtrT)] 

Let  message  ••  [Message  :  Module(RoPtr ,  )j 

In 

Ro  Pack  Use  ( get,  classjo_str,  fa3_proc.  byebye,  message )  In 
bn  ( user_detals :  unique  UserDetarfs ) 

Void  •>  String: 

Trappfy{  get.  user^details 
|  Op  ptrjJetails: 

Let  details :  UserDetaZs  -  0  ptr_deta.!$ 

Let  dear :  Class  -  Ud  Clear  details 
In 

class  to  str(  dear ) 

W 

|  Op  trap' 

Let  mess  -  lailj>roc<  trap ) 

In 

mess«go(  mess  Concat  • :  Pane1!  No  User  Deta2s  m  Context’ ), 
Fafure  IntToTrap  byebye 
Ni 

|Opjjmp:jumpO 

Endion 


WhatsMy Clearance  extracts  the  user_details  from  the  context  in  the  same  way  as  the  WhoAmI 
ion.  The  clearance  is  converted  from  a  class  into  a  string  using  the  procedure  class.to.str  from 
the  classifications  module.  If  no  user  details  are  found  in  the  context,  then  the  procedure  will  fail. 


10.2.6.  Whats  My  Clearance  Procedure 

The  WhatsMyCIearance  ion  is  closed  with  the  unique  for  user  details  to  give  a  procedure  which 
takes  a  void  and  returns  a  stnng. 

»n(  unique  UserDeta3$.  Void  •>  String ) 

N.B.  The  unique  for  user  details  geneiated  in  login  must  be  used  to  close  the  ion  as  follows  : 

Let  myclear :  Void  •>  String  •  uraque_ud  Close  mydearjon 


29 


i  0.2.7.  Am  I  On  The  Trusted  Path  Ion 


This  ion  will  determine  whether  the  user  is  on  the  trusted  path  when  it  is  closed  to  form  a 
procedure. 


Let  (..get)  -  {context :  Modulo{RoPtr..  )| 

Let  (. . fat!_proc)  -  {FailureNumbars :  Mo7ule(RoPtr.. )] 

Let  byebye  -  {byetya  :  ModulefRoPtfT)] 

Let  message  -  faessage  :  Module(RoPir.. ){ 


Ro  Pack  Use  ( get,  fa3j>roc.  byebye.  message )  In 
kvt  ( tpflag :  unique  TpFJag ) 

VtfcJ  •>  bool: 

Trapplyj  get.  tpflag 

I  Op  ptrjiag: 

let  flag :  TpFlag  -  D  pt/Jtag 
In 

(lag 

W 

|  Op  trap: 

let  mess  -  faitj>roc(  trap ) 

In 

message(  mess  Co  neat  • :  Pane'!  No  Trusted  Path  Flag  in  Context* ). 
Fa3ure  IntToTrap  byebye 
Ni 

|Opfjmp:j;mp<) 

Endion 


AmlOnTheTrustedPath  extracts  the  tpflag  from  the  context  using  the  procedure  get_context,  in  a 
way  similar  to  the  WhoAmI  ion.  If  get.context  succeeds  then  a  pointer  is  returned  which  is  dc- 
prted  to  return  the  value  of  the  flag.  If  there  is  no  trusted  path  flag  in  the  context  then  the  procedure 
fails  in  the  usual  way. 


10.2.8.  Am  I  On  The  Trusted  Path  Procedure 


The  AmlOnTheTrustedPath  ion  is  closed  with  the  unique  for  the  trusted  path  flag  to  give  a 
procedure  which  takes  void  and  returns  a  bool. 


ion(  unique  TpFlag,  Void  •>  bod ) 


The  same  unique  for  the  trusted  path  flag  as  generated  in  the  login  procedure  is  used  to  close  the 
ion  as  follows  : 


Let  tpath  •  Void  •>  Bool  *  umquejp  Close  tpath jon 


Tpath  is  then  used  as  a  non-local  in  a  procedure  which  takes  a  void  and  returns  a  string.  If  the 
tpath  procedure  returns  true  then  the  string  “You  are  on  the  Trusted  Path*  is  returned  If  tpath 
returns  false  then  the  string  "You  are  NOT  on  the  Trusted  Path"  is  returned 
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10.2.9.  Onjojp  and  Offjp  Ions 


These  ions,  when  closed  to  form 
the  trusted  path. 


procedures,  will  simulate  the  action  of  the  user  going  on  to  or  off 


Ut  (s«t..get) .  [context  :Modui»(RoPtr..)] 

( . fail_proc) «  [FailuraNumbers  ;  Module(RcPtr. 

Ut  bye  bye  .  fbyebye  j  Module(RoPtr„  )\ 

Let  message  -  (Message :  ModulofRoPir..")) 


Ro  Pack  Use  <  se,,  get,  fa3_proc.  byebye,  message )  In 
fon(tpf£ag;  unique  TpFUa) 

Void  ■>  VoW; 


Tf*pp!y{  gulping 

lOpptr  flag; 

H  (Not)  { D  plrjlag ) 
Then 


set(  tpfiag.  Pack  False  (True) ) 
Ft 

I  Op  trap: 

Let  mess  -  fail_prec<  trap ) 


Entfon 


Hsa':P,n'IINstaldP“^8nCo*“'1' 


K 

JOpJimpifcmPO 


c  procedure  get.context  is  used  within  the  operator  Tirapply  to  extract  the  trusted  path  flag  from 
the  context.  If  get  is  successful,  then  a  pointer  to  the  (lag  is  returned.  This  is  de-ptred.  and  the  flag 
is  re-set ,  as  appropriate  in  the  context.  If  the  trusted  path  flag  cannot  be  extracted  from  the  context 
then  the  procedure  fails. 


10.2.10.  On_to_tp  and  Off  Jp  Procedures 

returned* Cl°Sed  ^ U"iqU'  trU5t‘d  Path  fl>8 10  pve  proredures  wh'ch  void  and 
fen(  unxjua  Tpflas,  Vod  ->  Vod ) 

The  same  unique  for  the  trusted  path  flag  »s  generated  in  the  login  procedure  must  be  used  to  close 
the  ion  eg 

Letonpath :  Vow  •>  VoW  •  unique  jp  Close  onpaihjon 


10.2.11.  Review  My  Journal  Ion 


This  ion,  when  closed  to  form  a  procedure,  will  allow  the  user  to  examine  their  journal  as  long  as 
they  are  on  the  trusted  path. 


Lot  (..gal)  -  {context :  Modulo(RoPtr  ~)l 
Lot  (.review)  - 1  journal;  Module(RoPtrT)] 

Lot  (,..ftagJaif.,..ta!l_pfoc)  -  {FeituroNumbers  ;  Modu!o(RcPtr.~)] 
Lot  byebye  -  jbyobyo  :  Module(RoPtr7)| 

Lot  massage  -  (  Message  ;  Module|RoPtr.T)| 


Ro  Pack  Use  ( fov:ow,  gat.  flag  J&3,  fail _proc,  byebye.  message )  In 
ton  ( userjjetaJs :  unique  UsarOetals ) 

( tpflag :  unique  TpFlag ) 

Void  •>  Del: 

TrapptyJ  get.  userjJetails 
I  Op  ptr  details: 

Trapplyfget.  tpflag 

lOpptrJlag: 

If  D  ptrjiag 
Then 

Let  details :  UserDetaits  -  D  ptfjdeta'ls 
Let  journal :  Journal  -  Ud_Journal  details 
In 

review ( journal ) 

Mi 

Else 

Faituie  ImToTrap  flagjail 
Ft 

|Optrap:FaJuretrap 

|Op 

!  Op  trap: 

message(  falj>roc(  trap!  Concat  *  *  Pane"  No  User  Details  in  Context* ) ); 
FaJure  IntToTrap  byebye 
jOp^mpt^mpO 

Endion 

M 


ReviewMyJoumal  uses  the  procedure  get.context  within  the  operator  Trapply  to  retrieve  the  users 
details  from  the  context  Get.contest  is  then  used  again  within  Trapply  to  retrieve  the  trusted  path 
flag  from  the  context.  Assuming  the  trusted  path  flag  is  true,  then  the  user_details  are  de*ptred 
and  the  journal  field  is  extracted  from  the  structure.  The  review  journal  procedure  is  then  applied 
to  the  journal,  returning  a  Del.  If  get„context  fails  ie.  there  are  no  user  details  or  no  trusted  path 
flag  in  the  context  then  the  procedure  ReviewMyJoumal  will  also  fail. 


10.2.12.  Review  My  Journal  Procedure 

The  ReviewMyJoumal  ion  is  closed  with  the  unique  for  user  details  and  the  unique  for  the  trusted 
path  flag  to  give  a  procedure  that  takes  void  and  returns  a  Del 

ton(  unique  U$erDeta3$.  on(  unique  TpFUg,  Void  •>  Del ) ) 

The  same  uniques  generated  for  the  user  details  and  the  trusted  path  m  login  are  used  to  close  the 
ion  as  follows* 
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Lot  dosed :  »n(  umqy®  TpFlag.  Void  •>  Del )  -  un-quejjd  Close  reviewmyjournaljon 
Let  reviewmy/ournal :  Void  ■>  Del  «•  unique Jp  Close  closed 

Since  the  procedure  is  actually  required  to  return  Text,  which  is  a  persist  Del,  reviewntyjoumal  is 
passed  as  a  non-local  to  a  procedure  which  calls  Persist  on  the  result  of  the  reviewmyjournal 
procedure  call  so  returning  Text. 


The  Document  mode  is  defined  as  a  struct  of  three  fields,  the  classification  of  the  document,  the 
contents  of  the  document  and  the  document's  Journal,  as  follows: 

Document  •  struct(  Class  Class,  Del  Contents.  Journal  Journal ) 

The  registry  is  defined  as  a  vector  of  Document  entries  as  follows: 

Registry  -  vec(  Document,  Poslnt ) 


11.2.  PROCEDURES  IN  THE  REGISTRY  MODULE 


The  procedures  in  the  registry  module  are  written  as  ions,  they  are  read.document, 
revicw_documentjournal,  document_dass  and  create.document. 


11.2.1.  RcadJDocument 

Read.document  is  an  ion  which  can  be  closed  with  the  unique  for  user  details,  the  registry,  and 
the  trusted  path  flag  to  give  a  procedure  which  takes  the  edr  number  (  where  the  edr  number  of  a 
document  is  simply  its  position  in  the  registry ),  and  returns  the  text  of  the  document 

tel  (dom,.„)  -  Iclassilicanons :  Module(RoPtr~  )| 

Let  {..get )  *  (context :  Module(RoPtr.  )j 

Let  (add.)  -  (lournal :  Modul7(RoPtn7)j 

Let  (.dale.time)  -  fd«le_andjime  ;  Module(RoPtr.  )| 

Let  wtchar*  -  (intchars :  Module(RoPtr..  )1 

Let  (....cdrjal.dearjail.,)  .  (FailureNumbers .  ModuletRoPir.  )j 

Let  datastore  -  (datasiore  :  Module(RoPtf . )( 

Let  read^document  •  Use  ( dom,  get.  add,  date,  time,  intchars,  datastore,  cdMal,  clear  Jail )  In 
lon(  user_detajls :  unique  User  Oelafs ) 

( registry :  Registry ) 

( tpllag ;  unique  TpFlag ) 

( cdr„num :  Int )  •>  Text 

Tr  appfy{  get,  user_detai!s 
|  Op  ptr^deiaits” 

Trapp!y{  get.  tpflag 
|  Op  ptrjlag: 

B  (( cdr_num  <  l )  Orel  ( edr.  num  >  Upfc  @  registry )) 

Then 

Failure  IntToTrapcdrJai 
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Ut  user  -  Udjd  < D  ptr.detaJs ) 

Lei  user_c!ea7  •  Ud_C!ear  ( D  ptr_deta3s ) 

Lei  ujrnl  •  Ud.Journal  ( D  ptrjf  eta3$ ) 

Let  document  •  @  ( <§>  registry  Veclnd  cdrjium ) 
Let  doc.ctar  -  Class  document 
let  d jfftl  -  Journal  document 


Let  datejime  -  ©  dale  Ccnca:  time() 

In 

H  dom(  userjJear,  doc.dear ) 

Then 

Ut  tp.str  ■  'Opened  Document  *  Concat  ’CDR." 

Concat  intehar*(  cdr.num ) 

Let  offcp  -  tp.str  Concat ' :  Oil  TP' 

In 

R  D  ptrjlag 
Then 

add!  ujrnl  user.  tp.str,,  datejime ) 
add{  djrnt.  user,  tp  str,  datejime ) 

Else 

add(  ujrnl  user,  of  ftp,  datejime  ) 
add{  djrnt.  user,  offtp,  datejime  ) 

Fi; 

Persist!  Contents  document,  datastore } 

M 

Else 

Ut  mess  -  'Prevented  from  Opening  Document  CDf\.' 

Concat  mtchars(  cdr.num ) 

In 

add(  ujrnl  user.  mess,  date  time ) 

Ni; 

Fa.fure  IntToTrap  dearjal 


|  Op  trap:  Failure  trap 
jOp^mpt^mpO 

|  Op  trap :  FaJure  trap 
|Opfjmp:jump() 


Endion 


Get  .context  is  used  within  the  operator  Trapply  to  extract  the  user  details  from  the  context, 
returning  a  pointer  to  the  details,  Get.context  is  then  used  again  within  Trapply  to  extract  the 
trusted  path  flag,  returning  a  pointer  to  it.  U  the  user  details  and  trusted  path  flag  have  been 
successfully  extracted,  then  the  cdr  number  is  checked  to  ensure  that  it  is  within  range  ie.  greater 
than  or  equal  to  one  and  less  than  or  equal  to  Upb  registry.  If  either  of  the  get.context  procedure 
calls  fail  then  the  read.document  procedure  will  also  fail  using  the  Failure  operator. 

Assuming  the  cdr  number  is  in  range  it  is  used  to  extract  the  document  from  the  registry  vector.  If 
it  is  not  m  range,  then  the  procedure  will  fail.  A  check  is  then  done  to  ensure  that  the  clearance  of 
the  user  trying  to  read  the  document  is  greater  than  the  clearance  of  the  document  itself  This  is 
done  using  the  dominates  procedure  from  the  c^ssiflcations  module.  If  the  users  clearance 
dominates  the  document  clearance  and  the  user  is  on  the  trusted  path,  then  the  event  "Opened 
Document  cdr.num*  is  added  to  the  users  journal  along  with  the  dat  and  time,  and  the  same 
event  is  added  to  the  document  journal.  If  the  user  is  not  on  the  trusted  path,  then  "Off  TP"  is 
concatenated  onto  the  event  string  before  adding  it  to  the  user  and  document  journals  The 
contents  of  the  document  are  then  returned.  If  the  users  clearance  does  not  dominate  the 
classification  of  the  document  then  the  event  “Prevented  from  Opening  Document  cdr.num"  is 
added  to  the  users  journal,  along  with  the  date  and  time 
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11.2.2.  Review_DocumentJounttl 


Review_docJoumal  is  an  ion  which  can  be  closed  with  the  urique  for  user  details,  the  registry, 
and  the  trusted  path  flag  to  give  a  procedure  which  takes  the  cdr  number  of  a  document  and  returns 
the  text  of  the  journal. 


Let  (..get )  - 1 context :  ModuletRoPirT)] 

Let  (.review) -  (journal :  Module(RoPtrT)] 

Let  (.JlagJaJ.cdrJai,,,)  -  {FailuroNumbors :  Module(RoPtr..~)] 

Let  datastore  -  jdatastore  :  Module(RoPt7!7)| 

Let  rev!ew_doc Journal  -  Use  ( get.  review,  I  lag  Jail,  cdrjal,  datastore )  In 
ton  ( registry :  Registry ) 

( tpflag :  unique  TpFlag ) 

( cdrjium  tint)  •>  Text: 

Trapp!y{  get,  tpflag 
|  Op  ptrjlag: 

If  0  ptrjlag 
Then 

H  (( Cdrjium  <  \ )  Orel  ( cdrjium  >  Upb  @  registry )) 

Then 

Failure  IntToTrap  cdr  fail 
Else 

Let  document  -  @  @  registry  Veclnd  cdrjium ) 

Let  docjrnl  -  Journal  document 
In 

Persist  ( reviewf  docjrnl ),  datastore ) 

F. 

Else 

Failure  IntToTrap  flag  Jail 

j  Op  trap :  Failure  trap 
|Op^jmp:^jfripO 

End.on 


Get.context  is  used  within  the  operator  Trapply  to  extract  the  user  details  from  the  context.  If  this 
is  successful  then  a  pointer  to  the  user  details  is  returned  otherwise  the  procedure  falls.  The 
pointer  to  the  flag  is  de*ptred  using  D,  and  if  it  is  set  to  true  then  the  cdr  number  of  the  document  is 
checked  to  ensure  that  it  is  within  the  range  of  the  registry.  If  the  trusted  path  flag  is  false,  or  the 
cdr  number  is  out  of  range,  then  the  procedure  fails  using  the  operator  Failure. 

Assuming  all  the  checks  have  been  successful,  the  document  is  extracted  from  the  registry  using 
vector  indexing  on  the  cdr  number.  The  journal  is  then  extracted  from  the  Document  structure 
using  field  extraction,  and  the  procedure  reviewjournal  is  applied  to  review  the  journal 
Reviewjournal  returns  a  Del,  but  since  the  procedure  is  required  to  return  Text,  the  result  of  the 
reviewjournal  procedure  call  is  persisted  to  the  datastore. 
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11.2.3.  DocumenCClass 


Doc.class  is  an  ion  which  can  be  closed  with  the  registry  to  give  a  procedure  which 
number  of  a  document  and  returns  it's  classification  as  a  string. 


takes  the  cdr 


Let  (1,.dassjo_$tr1)  .  [classifications :  Mcdule(RoPtr..  jj 
Let  (....cdrjait,,) .  (FaifuteNumbers  :Module(RoPtf~)l 

let  doc„dass  -  Use  ( dassjo.str,  cdr  fal )  In 
•  ton  ( registry :  Registry ) 

( cdrjuim :  Int )  •>  String; 

IK(cdf./>un*  <  1 )  Ore!  ( cdrjwm  >  Upb  <§>  registry )) 

FaiJure  IntToTrap  cdr  lit 
Else 

Let  document »  @  ( @  registry  Veclnd  cdr  num ) 

Let  dasi :  Class  -  Class  document  *“ 

In 

j.  Document  classification  <«  •  Concat  clas$jo_$tr(  class ) 
fi 

Endion 


Tit'  0fth'd°C7'nl  !r“h“ked  10  ens“« il  ^  within  the  range  of  the  registry,  and  if  it 
s  not  then  the  procedure  fails.  The  document  is  then  extracted  from  the  registry  using  vector 

document  ^7  !  snd  th*  classification  of  the  document  is  extracted  from  the 

wave Tt£  T  7  P'°t  “r*  cI“5-l0-Str  from  ‘he  dMSifieations  module  is  then  used  to 
convert  the  class  to  a  stnng  which  is  returned  with  a  suitable  message. 

11.2.4.  Cicate.Document 


a “  i0"  WhiCh  **  Cl0S'd  wUh  U*  »•«  details,  the  registry,  and 

returns  vdd  *  *  Pr0"dUre  Whi'h  U!<'8  80m'  ,ext  and  “  '>*»ifi«t.on  string  and 


(»8®t )  -  jcoote xi ;  Module  (ftp  Pi  r.lH 
Lst  (add.)  •  [journal ;  Module  (RoPm.!) 

Ut  (■■■.strjo,dass.)  .  FcmsiticaiionsjModulalRopjr  “)) 
la!  create  Journal  -  Icreate.putnal ;  ModulefRoPtr..  ll 
La!  (,  Jlagjal,,.,) .  [FailureMumbers :  ModulelRoPtr  )| 

Lai  (.dala.tma)  -  [data  andjima t  Moduia(RoPtr.  )) 

“  csiejcumst  lt*ju  data.  ,  In 

( tpflag :  unique  Tpflag ) 

(registry :  Registry ) 

( la« :  Text.  class :  Stnng )  •>  Void 


Tr  appfy(  gat,  userjJetails 
|Opptr_da!ails. 
Trappfy{  gat,  tpflag 

jOpptrjiag- 
H  0  ptr Jlag 
Than 


Lat  usar  •  Udjd  ( 0  ptrjjeiaiis ) 

tat  what  •  ’Document  Journal  Created  *  *  Concat  dass 

tetdjrrd-  createjourna!(  what,  user ) 
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Lot  class  .  sir  Jo  class{  class  ) 

Let  text  *.  Del  -  UnPerslst  text 

Let  doc :  Document  -  { dass,  text,  djrm ) 

Var  new :  Registry  >  Vec(  t  Of  doc) 

In 

registry  >  @  registry  Concat  @  new 
Ni 

Else  v 

Let  user  -  Ud  td  ( D  ptr_de!afe ) 

Let  ujrnl  -  lid  Journal  ( D  ptr_deta2s ) 

Let  date  time  -  @  date  Concat  time() 

Let  mess  -  ’Attempt  to  Create  a  Document ;  Not  on  TP 
In 

add{ujrnl  user.  mess,  datejsne ) 

Nr: 

Failure  IntToTrapflagJaJ 
R 

l  Op  trap :  Fa3ure  trap 
|Op*jmp;fjmp<) 

) 

I  Op  trap :  Fa3ure  trap 
tOpfcjmpt^mpO 

Endion 

Get.context  is  used  within  the  operator  Trapply  to  extract  the  user  details  from  the  context, 
returning  a  pointer  to  the  details.  Get.contert  is  then  used  again  within  Trapply  to  extract  the 
trusted  path  flag,  returning  a  pointer  to  it.  If  either  of  the  calls  of  get_context  are  unsuccessful, 
then  the  procedure  will  fail.  If  the  trusted  path  flag  is  set  to  true,  then  the  user's  td  is  extracted  from 
the  details  and  a  journal  is  created  using  the  procedure  create  journal  with  the  user  s  id  and  the 
string  -Document  Journal  Created  :  "  Concat  class  {where  class  is  the  result  of  applying 
str.to.class  to  the  class  string  given  as  parameter  to  the  create.document  procedure)  as 
parameters. 

The  text  supplied  to  the  procedure  is  unpersisted  to  give  a  Del,  and  a  new  document  is  formed 
using  the  class,  the  text,  and  the  newly  created  document  journal.  This  new  document  is  then  used 
to  form  a  new  entry  for  the  registry,  which  is  then  concatenated  on  to  the  end  of  the  existing 
registry  vector. 

If  the  user  is  not  on  the  trusted  path,  then  the  string  "Attempt  to  Create  a  Document :  Not  on  TP'  is 
added  to  the  user's  journal  along  with  the  date  and  time,  then  the  procedure  fails. 
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31.2.5.  Registry  procedures 

Each  of  the  above  four  ions  are  closed  within  the  module  registry  procedures,  and  the  failures  are 


Firstly  the  variable  registry  is  created  as  a  zero  length  vector  with  dummy  entries  as  follows: 


L«t  {.  ) ,  l[tTn>_unicuos  :  Modulo  (RoPtr.,  )| 

Let  {,  deJ_v#rt_u )  - 1 vorumiquos":  Module(RoPtf .  )j 

Let  some  text  *  Use(  dol_simpi#  Sn#  u,  del  vert  u )  In 
PfOc(mesie3e:  String  )■>  D«l;  *  * 

rL!lirJ°^'tsi5St?rSmR,8Un®{PackAjL5n#m«ssa3®«<,»!  *mP!«  tne  u) 

Let  vertcat *  AsOelVec  Voe{  I  Of  AsDel  t )  “  K  -  ~ ' 

Let  va  -  ToExI$tsDelVec{  Pack  vertical,  d*l_vortj; ) 

va 

NS 

Endproc 


Let  dummy  Journal ;  Journal  -  createjouma!(  'dummy*,  'dummy* 
let  dummyjJoc ;  Document  *  ( CrCtass  1,  $omojoxl(  'dummy' ), 


) 

dummyjournal) 


Var  registry :  Registry  .•  Vec{  0  Of  dummy_doc ) 


Each  of  the  four  ions  are  then  closed  with  the  appropriate  uniques  and  the  registry  as  follows: 

Let  unique_[p :  unique  TpFlaj  .  [A  :  Umcue  Booil 
Let  unique^ud :  Unique  User  Details  -  :  UnlqueTl) 

u!  ctosed2  ■'  &{  F?>5' Inl  ->  T,xl  1  >  ■  uni<i"s-ud  CIOS,  read.doc  ion 

J- .  COS602 .  K>n{  unique  TpFJag,  Lit  •>  Text ) .  registry  Close  ciosedi 
Let  read_doc :  int  •>  Text  -  uruquojp  Ctese  do$ed2 

,‘i w •> Tea ) . regutry Close review.docjournal  on 
let  revsew^doc;  Int  •>  Text  -  oniquejp  Close  rd^ebsed 

Let  doc_dass :  Int  •>  String  •  registry  Close  doc^dass  tort 

let  cd.cbsedt :  on(  unique  TpFlag.  onj  Rejisty.  struct!  Text.  Stung )  •>  Void )) .  umque.ud 

:  l?nin¥'*,'yi*’fuct<  T,H"  S!*s  >*>  Void).  umqu^°tp*WMe  edcSsedi 
lot  oreete_doo :  struct!  Texi  Suing )  •>  Void  .  reguuy  Close  cd.closed2 


N.B.  The  unique  for  the  user  details  and  the  unique  for  the  trusted  path  flag  are  identical  to  those 
created  rn  the  login  procedure.  In  fact  throughout  the  whole  SERCUS  demonstration,  wherever 
these  values  are  required,  those  created  in  login  are  used. 


Havmg  closed  the  four  ions,  procedures  are  defined  for  each  ion  which  catch  and  deal  with 
exceptions  caught  in  the  ions  and  propagated.  The  general  form  of  these  procedures  is  the  operator 
"aPP!y  wfncfl  the  result  of  the  procedure  closed  from  the  relevant  ion  if  the  procedure  was 
successful,  or  a  VduMessage  diagnosing  the  error  if  the  procedure  closed  from  the  ion  failed 
followed  by  a  fatal  Failure,  eg. 
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L#t  Message  -  {message  :  Module(RoPtrT)] 

UJ  read  •  Us*  ( readjioc.  la3_proc,  byeby® )  In 
Proc  ( cdf.num :  lm )  •>  Text: 

Trapp!y{  f**d.doc.  cdr_num 
|  Op  t*xt ;  texf 
|  Op  trap. 

Let  m®ss*g®  -  fal _proc(  trap ) 
In 

Mo$sag®(  message ); 

^  Faiur®  ImToTrap  byeby® 

|Opjump:jumpO 

Endproc 
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